home *** CD-ROM | disk | FTP | other *** search
/ Internet Tools (InfoMagic) / Internet Tools.iso / dos_win / winsock / maillist / 94-05.Z / 94-05 / 000310_davidtr@microsoft.com_Sat May 21 09:55:00 1994.msg < prev    next >
Internet Message Format  |  1994-05-31  |  24KB
  1. Received: from netmail2.microsoft.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  2.           id AC17389; Sun, 22 May 1994 19:08:09 -0400
  3. Received:  by netmail2.microsoft.com (5.65/25-eef)
  4.     id AA04158; Sun, 22 May 94 15:09:43 -0700
  5. Received: by netmail2 using fxenixd 1.0 Sun, 22 May 94 15:09:42 PDT
  6. Message-Id: <9405222308.AA10020@itgmsm>
  7. From: davidtr@microsoft.com
  8. To: winsock@sunsite.unc.edu
  9. Subject: *** WinSock 2 Framework Doc ***
  10. Date: Sat, 21 May 94 16:55:00 PDT
  11. X-Mailer: Microsoft Mail V3.0
  12.  
  13.  
  14. Below is the latest revision of the Windows Sockets 2.0 framework document. 
  15.  It includes changes based on the Interop meeting and other feedback we've 
  16. received.
  17.  
  18. Please note that the deadline for volunteering as a group administrator is 
  19. this Tuesday, May 24.  As outlined in previous mail, please contact 
  20. martinh@jsbus.com if you are interested.
  21.  
  22. Martin, Mark, and Dave
  23.  
  24.  
  25.  -----------------------------------------------
  26. Windows Sockets Version 2 - Operating Framework
  27.  -----------------------------------------------
  28.  
  29. Date:             May 20, 1994
  30. Project Status:   Phase 1
  31. Authors:          Martin Hall, Dave Treadwell, Mark Towfiq
  32.  
  33. This document is organized as follows
  34.  
  35. 1. Objectives (Why are we doing this?)
  36. 2. Mission Statement
  37. 3. Overview  (What's it all about?)
  38. 4. Specification Paramaters & Requirements
  39.           4.1 General Referential Paramaters
  40.           4.2 Technical Requirements
  41. 5. Organizational Framework
  42.         5.1 Moderators
  43.         5.2 Review Boards
  44.                 5.2.1 Review Board Administrators
  45.                 5.2.2 Application Review Board
  46.                 5.2.3 Transport Review Board
  47.         5.3 Functionality Groups
  48.                 5.3.1  Functionality Group Administrators
  49.                 5.3.2  Generic API Extensions & Additions
  50.                 5.3.3  Specification Clarifications
  51.                 5.3.4  Name Resolution
  52.                 5.3.5  Operating Framework
  53.                 5.3.6  TCP/IP
  54.                 5.3.7  IPX/SPX
  55.                 5.3.8  Appletalk
  56.                 5.3.9  Connection-Oriented Media
  57.                 5.3.10 OSI
  58.                 5.3.11 Wireless
  59. 6. Timeframes (Project Phases)
  60. 7. Discussion Forums
  61.  
  62.  ------------
  63. Introduction
  64.  ------------
  65. This is a rolling document that defines the framework for the
  66. creation of the Windows Sockets Version 2 specification. As the
  67. document is changed, the date at the head will change. Please note
  68. the status indicates the phase we are in as laid out in the
  69. Timeframes section in this document.
  70.  
  71.  --------------------------------------
  72. 1. Objectives (Why are we doing this?)
  73.  --------------------------------------
  74. Windows Sockets has succeeded to date because
  75. 1. It has met the needs of application developers ("I'm tired of all these
  76. different API's!")
  77. 2. It has led to easier decisions for end users ("I want a Windows Sockets
  78. app, I want a Windows Sockets compliant stack and I want them now!")
  79. 3. It's been fun and pursued in a great spirit of cooperation
  80.  
  81. The burgeoning implementation of LAN environments, the rise and rise of
  82. TCP/IP, the widespread acceptance of Windows Sockets in the application
  83. developer community and amongst application users have all helped make
  84. Windows Sockets something of a de facto standard in a very short period of
  85. time. It is therefore natural to consider amending and extending Windows
  86. Sockets to make it the de facto transport API for all data communication
  87. irrespective of protocol.
  88.  
  89.  --------------------
  90. 2. Mission Statement
  91.  --------------------
  92. The goal of Windows Sockets 2 is to make it a ubiquitous transport level
  93. API available in all Windows operating systems and capable of supporting
  94. multiple data transports simultaneously. It will allow flexible addition
  95. of transport functionality while providing a consistent API base for
  96. straightforward application development. Windows Sockets 2 will standardize
  97. the API such that similar functionality in different transports will be
  98. accessible via common mechanisms. It will also provide mechanisms for
  99. applications to access essential characteristics that are specific to
  100. particular classes of transports.
  101. All this serves to help reach the ultimate goal of Windows Sockets: to
  102. provide a truly transport-independent API that allows developers to create
  103. transport-independent and transport-efficient applications and allows users
  104. to select applications based on functional merit rather than the transports
  105. they support.
  106.  
  107.  ----------------------------------
  108. 3. Overview (What's it all about?)
  109.  ----------------------------------
  110. The Windows Sockets Version 2 specification will extend Windows Sockets
  111. Version 1.1 in 3 key areas
  112.  
  113. 1. API Extensions
  114. Over 2 years experience of Windows Sockets has led to various suggestions
  115. for improvements to the existing specification. There are a number of
  116. proposals for API additions and extensions which make it even easier for
  117. application developers to utilize Windows Sockets implementations.
  118. Some of these extensions are likely to be generically applicable, some will
  119. be transport specific.
  120.  
  121. 2. Multiple Network Transport Capabilities
  122. The success of version 1.1 of Windows Sockets has led to a clamor for
  123. support of network transports other than TCP/IP. Requests have been
  124. made to design support for IPX/SPX, Appletalk, OSI and DECnet specifically.
  125. In response to demand for a standard data transfer API for emerging
  126. technology such as ATM and telephony-based transports, there will also be
  127. consideration of how best to enable this in a Windows Sockets framework.
  128. The design groups in Windows Sockets 2 will also seek to create a generic
  129. architectural framework that will host any network transport.
  130.  
  131. 3. Operating System Considerations & Architectural Issues
  132. The Microsoft Windows Operating System platforms will soon be extended
  133. beyond Windows 3.1 and Windows NT for which Windows Sockets 1.1 was
  134. designed. Windows Sockets Version 2 will take into account not just
  135. these platforms but forthcoming versions of both Windows NT and
  136. Chicago. An important goal of Windows Sockets 2 is thus ensuring that
  137. Windows Sockets applications can be well-integrated within these
  138. operating systems.
  139.  
  140.  ---------------------------
  141. 4. Specification Parameters
  142.  ---------------------------
  143.  
  144. 4.1 General Referential Parameters
  145.  ----------------------------------
  146. The following list of parameters is designed to help us all clearly
  147. understand the parameters around what we are trying to achieve. Windows
  148. Sockets 1.1 succeeded in part because we had a clear set of parameters
  149. against which to measure and judge the specific applicability of any
  150. particular piece of functionality. Everything we consider in every
  151. Functionality Group should be prescribed by the following parameters.
  152. Please note that these parameters are numbered for easy reference.
  153.  
  154. 1.  Don't introduce API changes that preclude a vendor from
  155.     simultaneously supporting 1.1 and future versions
  156.  
  157. 2.  Enable Windows Sockets 1.1 apps to become Windows Sockets 2 apps with
  158.     minimal code changes
  159.  
  160. 3.  The only changes to the Windows Sockets 1.1 API set will be
  161.     specification clarifications
  162.  
  163. 4.  New functionality will be added in such a way that it's clearly
  164.     distinguishable from the Windows Sockets 1.1 API set
  165.  
  166. 5.  Wherever possible, new API's should be supersets of old API's
  167.  
  168. 6.  Follow existing precedents.
  169.     For example, we will continue to use BSD 4.3 Sockets as a guiding
  170.     model where possible. Where recognized work has already been
  171.     done in a particular area we should make use of it.
  172.  
  173. 7.  Windows Sockets 2 specification to be complete and final by April 30, 
  174. 1995
  175.  
  176. 8.  Facilitate high performance implementations.
  177.  
  178. 9.  New functionality to be driven by application and end user
  179.     requirements.
  180.  
  181. 10. Don't try to do everything; prioritize proposed changes & additions
  182.     and focus on highest priority items.
  183.  
  184. 11. Where possible, implement functionality generically.
  185.     We want to ensure that we solve similar problems worked on
  186.     by different Functionality Groups in a common and consistent way.
  187.  
  188. 12. Enable transport-independent applications. It should be possible
  189.     to write an application that works over any transport without
  190.     knowing the details of any one transport.
  191.  
  192. 13. Enable transport-efficient applications. It should be possible
  193.     to write a transport-specific application that takes advantage
  194.     of special features of a particular transport.
  195.  
  196. 14. Mandatory functionality for any particular transport must be consistent
  197.     and logical.
  198.  
  199. 15. Ensure that proposed functionality changes & additions mesh with
  200.     each other and with Windows API's and operating system services.
  201.  
  202. 16. Windows Sockets is not SNMP.
  203.  
  204. 17. Optional functionality should be generally useful and the exception
  205.     rather than the rule.
  206.  
  207. 4.2 Technical Requirements
  208.  --------------------------
  209. Each Functionality Group will have a clear set of requirements which
  210. define the problems it is trying to address. The initial work of each
  211. Functionality Group will be to define these requirements in the context
  212. of the Referential Parameters set out above.
  213.  
  214.  ---------------------------
  215. 5. Organizational Framework
  216.  ---------------------------
  217. The success of Windows Sockets 1.1, the complexity and breadth of issues
  218. under discussion for Windows Sockets version 2 and the number of people
  219. now involved in the various Windows Sockets forums means we need a clearer
  220. operational structure for progress this time around.
  221.  
  222. In order to allow everyone to contribute to areas which they care
  223. about we have designed the following operational structure to
  224. facilitate discussion and to enable maximum progress. The most
  225. important groups are the Review Boards and Functionality Groups.
  226. Together, these groups will be responsible for discussing, agreeing and
  227. designing new functionality.
  228.  
  229.  --------------
  230. 5.1 Moderators
  231.  --------------
  232. Martin Hall, Dave Treadwell and Mark Towfiq will act largely as
  233. coordinators of the Windows Sockets 2 effort. They will be responsible
  234. for:
  235.  
  236. * Coordinating the various groups to ensure that the process
  237.   moves in the right direction.
  238.  
  239. * Facilitating information flow between the groups so that new
  240.   features are implemented consistently.
  241.  
  242. * Producing the consolidated header file for Windows Sockets 2.
  243.  
  244. * Working with the Review Boards to help consolidate specification
  245.   sections produced by the Functionality Groups.
  246.  
  247. * Handling public relations for Windows Sockets 2.
  248.  
  249. * Working with the Review Boards to address discrepancies between the
  250.   work produced by each Functionality Group.
  251.  
  252.  -----------------
  253. 5.2 Review Boards
  254.  -----------------
  255. The reason for establishing Review Boards is to enable the ongoing
  256. pragmatic goals of Windows Sockets to be realized. In the world of
  257. Windows Sockets, pragmatism is defined by
  258.  
  259. 1. The applicability of Windows Sockets functionality to application
  260.    developers.
  261. 2. The ease with which functionality can be implemented by
  262.    Windows Sockets providers (typically, but not necessarily,
  263.    network transport vendors)
  264.  
  265. To this end, there will be 2 Review Boards. Each board will
  266. review submissions from each Functionality Group in the light of the
  267. pragmatic goals of Windows Sockets. Each Review Board will have an
  268. administrator with responsibilities as outlined above.
  269.  
  270. 5.2.1 Review Board Administrators
  271.  ---------------------------------
  272. The responsibilities of the administrator of each Review Board are to
  273. ensure:
  274.  
  275. * Refinement of requirements initially proposed by Functionality Groups
  276.  
  277. * Progress according to the key milestones
  278.  
  279. * Discussions framed by general referential paramaters
  280.  
  281. * Design decisions meet the referential paramaters and the Windows Sockets 2
  282.   requirements
  283.  
  284. * Consistency of proposals from Functionality Groups
  285.  
  286. * Arrangement of meetings on an as needs basis
  287.  
  288. * Regular communication with moderators
  289.  
  290. 5.2.2 Application Review Board
  291.  -------------------------------
  292. Charter: The Application Review Board will review submissions from
  293.          each Functionality Group. It will focus on the submission's
  294.          applicability to and ease of use by application developers as
  295.          well as confirming that functionality required by applications
  296.          is supported.
  297.  
  298. Membership: A maximum of one representative from each company will
  299.             contribute to this group.
  300.  
  301. 5.2.3 Transport Review Board
  302.  -----------------------------
  303. Charter: The Transport Review Board will review submissions from
  304.          each Functionality Group. It will focus on the ease of
  305.          implementation of a piece of functionality.
  306.  
  307. Membership: A maximum of one representative from each company will
  308.             contribute to this group.
  309.  
  310. 5.3 Functionality Groups
  311.  ------------------------
  312. The reason for establishing Functionality Groups is to break up
  313. the large body of issues that require discussion for Windows Sockets 2 into
  314. manageable chunks. The following groups will also allow people to focus
  315. on areas of particular interest and ignore ones they don't care about.
  316.  
  317. Each Functionality Group will have an administrator responsible for
  318. coordinating the group's discussion and ensuring that the general
  319. parameters and timeframes for Windows Sockets 2 are met.
  320.  
  321. Please note that at this point the proposals listed below are just that.
  322. Each group will define the actual requirements which may lead to the
  323. exclusion of some proposals listed below and/or the inclusion of others
  324. not listed. Phases 1 and 2 as outlined below will see the production
  325. of a Requirements Document for each Functionality Group.
  326.  
  327. 5.3.1 Functionality Group Administrators
  328.  ----------------------------------------
  329. The responsibilities of the administrator of each Functionality
  330. Group are to ensure:
  331.  
  332. * Progress according to the key milestones
  333.  
  334. * Regular communication with other functionality groups
  335.  
  336. * Discussions framed by general referential paramaters
  337.  
  338. * Design decisions meet the referential paramaters and the group's
  339.   requirements
  340.  
  341. * Arrangement of meetings on an as needs basis
  342.  
  343. * Regular communication with moderators
  344.  
  345. * Ultimate responsibility for producing actual specification sections
  346.   for the group
  347.  
  348. * Moderation of the group's mailing list: keep high signal-to-noise ratio
  349.  
  350. 5.3.2 Generic API Extensions & Additions
  351.  -----------------------------------------
  352. Charter: To design and specify general extensions to the Windows Sockets
  353.          API. Features and changes should be applicable to multiple
  354.          transport protocols.
  355.  
  356. Proposals:
  357.     Improved support for other languages: C++, Basic, Pascal
  358.     True asynchronous send() and recv() mechanisms
  359.     Ability to share sockets between tasks/processes
  360.     "Deferred accept()"--don't establish connection immediately
  361.     SO_SNDTIMEO and SO_RCVTIMEO socket options
  362.     4-byte per-socket context value stored by Windows Sockets DLL
  363.     Standard routine to map Windows Sockets error codes to strings
  364.     Application yielding, blocking hooks
  365.     Socket Groups
  366.     Support for message-oriented (partial) receives
  367.     Per-socket query of max message length
  368.     Support for connect and disconnect data
  369.     Transaction-oriented transport support
  370.     Mechanism for querying optional functionality
  371.     Scatter write, gather read
  372.     sethostname()
  373.     Mechanism to retrieve network statistics
  374.  
  375. 5.3.3 Specification Clarifications
  376.  -----------------------------------
  377. Charter: Resolve ambiguities in the Windows Sockets specification to
  378.          ensure that all Windows Sockets implementations have a
  379.          consistent interpretation of the interface.
  380.  
  381. Proposals:
  382.     WSAAsyncSelect() issues
  383.     Multiple versions supported by a single Windows Sockets DLL
  384.     Unconnecting datagram sockets
  385.     FD_CLR performance improvements
  386.     s_port in servent struct is int
  387.     Stack space requirements on winsock DLL
  388.     NULL array pointers in hostent struct
  389.     Structure packing of servent, protoent
  390.     winsock.h: all ports, ip addrs in NETWORK order
  391.     closesocket() on nonblocking sockets
  392.     Samples for every API
  393.     FD_READ contains error--> no need for recv()
  394.  
  395. 5.3.4 Name Resolution
  396.  ----------------------
  397. Charter: Design and specify a name-service independent interface which
  398.          allows Windows Sockets applicationt to resolve huiman-readable
  399.          host or service names into Windows Sockets transport addresses
  400.          (SOCKADDRs).
  401.  
  402. Proposals:
  403.     Support for other name service providers
  404.     Host/Service enumeration
  405.     Internationalizable (unicode) name resolution routines
  406.     Dynamic service registration
  407.     Directory Service support
  408.     Define standard location for database files
  409.  
  410. 5.3.5 Operating Framework
  411.  --------------------------
  412. Charter: Ensure that Windows Sockets DLLs and transport protocols can
  413.          coexist in the various operating systems which support Windows
  414.          Sockets.
  415.  
  416. Proposals:
  417.     Operating System versions--Win 3.1, WFW, NT, Chicago
  418.     Configuration
  419.     Architecture
  420.     Multiple Transport Procotol Stacks on a single host via a single DLL
  421.     Multiple Windows Sockets DLLs on a single host
  422.     Clearinghouse for address familys, protoocls, socket types
  423.     Mechanism for determining version of winsock DLL
  424.  
  425. 5.3.6 TCP/IP
  426.  -------------
  427. Charter: Provide TCP/IP-specific extensions to the Windows Sockets API.
  428.  
  429. Proposals:
  430.     ICMP, Raw Sockets, Ping
  431.     RFC 793 & 1122 OOB Data support
  432.     Get/Set/Delete ARP entries
  433.     gethostid()
  434.     SIOCGIFADDR, SIOCGARP, SIOCGHIWAT, SIOCGIFNETMA
  435.     Mechanism to set TTL in IP header
  436.     rresvport()
  437.     IP multicast support (IGMP)
  438.     IPng support
  439.     UDP datagram send size != receive size
  440.     Standardize OOB handling
  441.     Option to disable UDP checksum
  442.  
  443. 5.3.7 IPX/SPX
  444.  --------------
  445. Charter: Provide IPX/SPX-specific extensions to the Windows Sockets API.
  446.  
  447. Proposals:
  448.     No specific ones as yet
  449.  
  450. 5.3.8 AppleTalk
  451.  ----------------
  452. Charter: Provide AppleTalk-specific extensions to the Windows Sockets API.
  453.  
  454. Proposals:
  455.     No specific ones as yet
  456.  
  457. 5.3.9 Connection-Oriented Media (formerly Telephony)
  458.  ----------------
  459. Charter: Extend Windows Sockets to handle connection-oriented
  460.          physical media including ATM, ISDN, etc.
  461.  
  462. Proposals:
  463.     Lots of interest
  464.  
  465. 5.3.10 OSI
  466.  ----------------
  467. Charter: Provide OSI-specific extensions to the Windows Sockets API.
  468.  
  469. Proposals:
  470.     No specific ones as yet
  471.  
  472. 5.3.11 Wireless
  473.  ----------------
  474. Charter: Provide Wireless-specific extensions to the Windows Sockets API.
  475.  
  476. Proposals:
  477.     No specific ones as yet
  478.  
  479.  ------------------------------
  480. 6. Timeframes (Project Phases)
  481.  ------------------------------
  482. We have identified the following timeframes for Windows Sockets
  483. Version 2. Please note that the overall project is broken into
  484. phases so we can easily identify where we are.
  485.  
  486. PHASE 1 - Create First Functionality Group Requirements Drafts
  487.  --------------------------------------------------------------
  488. Functionality Groups create initial Requirement Drafts.
  489. Functionality Group Administrators submit this draft to
  490. the mailing list of each Review Board by Completion Date.
  491.  
  492. Completion Date:        June 6 1994
  493.  
  494. PHASE 2 - Create Final Functionality Group Requirements Drafts
  495.  --------------------------------------------------------------
  496. Review Boards consider the Requirement Drafts.
  497. Functionality Groups refine the Requirement Drafts based on
  498. input from Review Boards.
  499. Functionality Group Administrators submit the final draft to
  500. the mailing list of each Review Board by Completion Date.
  501.  
  502. Completion Date:        Jun 30 1994
  503.  
  504. PHASE 3 - Create first draft Functionality Group specifications
  505.  ---------------------------------------------------------------
  506. Functionality Groups work on solutions in the context of
  507. the Requirements Document for their group.
  508. Functionality Group Administrators submit their Functionality Group's first
  509. draft specification to the mailing list of each Review Board by Completion
  510. Date.
  511.  
  512. Completion Date:        Aug 31 1994
  513.  
  514. PHASE 4 - Create intermediate draft Functionality Group specifications
  515.  ----------------------------------------------------------------------
  516. Review Boards consider the first draft specifications.
  517. Functionality Groups refine the first draft specifications based on
  518. input from Review Boards.
  519. Functionality Group Administrators submit the intermediate draft
  520. specifications tothe mailing list of each Review Board by Completion Date.
  521.  
  522. Completion Date:        Nov 30 1994
  523.  
  524. PHASE 5 - Preliminary Interoperability Testing
  525.  ----------------------------------------------
  526. It is expected that software vendors will be working on Windows Sockets 2
  527. implementations as the specification evolves. This phase will include
  528. the first interoperability testing for Windows Sockets Version 2.
  529.  
  530. Date:                   Jan 1995
  531.  
  532. PHASE 6 - Create final draft Functionality Groups specifications
  533.  ----------------------------------------------------------------
  534. Review Boards consider the intermediate draft specifications & results
  535. of interoperability testing.
  536. Functionality Groups refine draft specs based on Review Board input and
  537. interoperability testing.
  538. Functionality Group Administrators submit the final draft specifications to
  539. the mailing list of each Review Board by Completion Date.
  540.  
  541. Completion Date:        Feb 28 1995
  542.  
  543. PHASE 7 - Interoperability Testing
  544.  ----------------------------------
  545. This phase will include further interoperability testing for
  546. Windows Sockets Version 2.
  547.  
  548. Date:                   Mar 1995
  549.  
  550. PHASE 8 - Complete Windows Sockets 2 specification
  551.  ------------------------------------------
  552. Review Boards consolidate and refine specification.
  553. Windows Sockets 2 specification completed and published by;
  554. completion date.
  555.  
  556. Completion Date:        Apr 30 1995
  557.  
  558.  ---------------------
  559. 7. Discussion Forums
  560.  ---------------------
  561. Email & Newsgroup details
  562.  
  563. With the recent reorganization of the Windows newsgroups, we see a need
  564. to:
  565.  
  566. 1. Create new mailing lists for Windows Sockets 2
  567. 2. Shift the mailing list gated to alt.winsock
  568. 3. Re-think winsock-hackers and winsock-users.
  569.  
  570. Here are the new networking-related newsgroups
  571.  
  572. comp.os.ms-windows.networking.tcp-ip     Windows and TCP/IP etworking
  573. comp.os.ms-windows.networking.windows    Windows' built-in networking
  574. comp.os.ms-windows.networking.misc       Windows and other networks
  575. comp.os.ms-windows.programmer.networks   Network programming
  576.  
  577. For the current mailing lists we propose to
  578. 1. Gate the present winsock mailing list to
  579. comp.os.ms-windows.networking.tcp-ip
  580.  (since, although winsock is not only for TCP/IP, 95% of the traffic on the
  581. mailing list is about TCP/IP).
  582. 2. Gate winsock-hackers to comp.os.ms-windows.programmer.networks.
  583. 3. Drop winsock-users because of minimal usage.
  584.  
  585. For Windows Sockets Version 2 discussion we propose to
  586. 1. Create a new mailing list for discussion of general issues related
  587. to Windows Sockets version 2.
  588. 2. Create separate mailing lists for individual Review Boards and
  589. Functionality Groups.
  590.  
  591. None of these will be gated to a newsgroup, to facilitate focussed
  592. discussion.
  593.                                                                               
  594.  
  595.  
  596.  -------------------------------------------------------------------------
  597. Martin Hall                         108 Whispering Pines Drive, Suite 115
  598. JSB Corporation                     Scotts Valley, California 95066
  599. martinh@jsbus.com                   Tel: 408-438-8300   Fax: 408-438-8360